⚠️ Potential issue | 🟡 Minor

Auth status detection works; fix unused exception variable and consider future‑proofing naming heuristics

The heuristic over *.json files in CONFIG_DIR to infer provider auth state is a practical solution and should work fine with your current naming conventions.

Two small issues:

• In the except block you use except Exception as e: but never reference e. This is what Ruff flagged (F841). Either drop the as e or log the exception somewhere.
• The string‑matching heuristics ("gemini" in name or "@gmail.com" in name, "copilot" in name or "github" in name, etc.) are tightly coupled to current filenames. If you change how auth artifacts are named, it would be easy to drift. Not urgent, but eventually a small metadata file listing authenticated providers would be more robust.

Proposed minimal fix for the unused variable:

-        except Exception as e:
-            self.send_json({p: False for p in ["gemini", "antigravity", "copilot", "codex", "claude", "qwen", "iflow", "kiro"]})
+        except Exception:
+            self.send_json({p: False for p in ["gemini", "antigravity", "copilot", "codex", "claude", "qwen", "iflow", "kiro"]})

In scripts/cliproxyapi-api-server.py around lines 188 to 225, the except block
declares an unused exception variable ("except Exception as e:") which triggers
a linter warning; change it to "except Exception:" (or log the exception via
process logger) and keep the fallback JSON response as-is; optionally consider
replacing the filename-heuristic with a small metadata file for provider auth
detection in future to avoid brittle name matching.

⚠️ Potential issue | 🔴 Critical

Bind server to localhost only to avoid exposing control API on the network

Right now you instantiate the server as:

with socketserver.TCPServer(("", PORT), APIHandler) as httpd:

Passing "" binds to all interfaces (0.0.0.0), which exposes this management API — including start/stop, OAuth triggering, config access, and update commands — on any reachable network interface. Given this is a local control plane for a desktop tool, that’s a security risk and unnecessary.

You almost certainly want to bind only to the loopback interface so it’s only accessible from the local machine:

-    with socketserver.TCPServer(("", PORT), APIHandler) as httpd:
+    with socketserver.TCPServer(("127.0.0.1", PORT), APIHandler) as httpd:

This still works seamlessly with the bundled GUI (which talks to localhost) but prevents other machines on the network from hitting these endpoints directly.

In scripts/cliproxyapi-api-server.py around lines 292 to 307, the server is
currently bound to all interfaces via socketserver.TCPServer(("", PORT),
APIHandler) which exposes the control API on the network; change the bind
address to the loopback (e.g., "127.0.0.1" or "localhost") so the TCPServer
listens only on localhost (socketserver.TCPServer(("127.0.0.1", PORT),
APIHandler)), keeping the GUI functional while preventing remote access.

⚠️ Potential issue | 🟡 Minor

Unused color variable MAGENTA.

The MAGENTA variable is defined at line 54 but never used in the script. The color initialization includes MAGENTA but only GREEN, CYAN, YELLOW, RED, and NC are actually used.

Either remove the unused variable or apply it to the banner output for consistency with other scripts.

In scripts/gui-cliproxyapi.sh around lines 49 to 61, the MAGENTA color variable
is defined but never used; remove the unused MAGENTA assignment or apply it to
an appropriate output (for example the banner) to keep color definitions
consistent. If removing, delete the MAGENTA line; if applying, change one echo
that should stand out (e.g., banner or header) to use ${MAGENTA}...${NC} and
ensure the echo function or literal uses -e so escape codes render correctly.

⚠️ Potential issue | 🟠 Major

HTTP server startup logic could fail silently on Python API server.

The script attempts to start the API server (line 190) without verifying it's executable or properly handling stderr. If python3 "$API_SERVER" fails to start or exits, the fallback HTTP server won't start because the first command terminates the script execution (due to set -e at line 7).

Apply this fix to ensure fallback works:

 API_SERVER="$HOME/.local/bin/cliproxyapi-api-server"
 if command -v python3 &> /dev/null; then
     if [ -f "$API_SERVER" ]; then
-        # Use Python API server with management endpoints
-        python3 "$API_SERVER" 2>/dev/null
+        # Use Python API server with management endpoints
+        python3 "$API_SERVER" 2>/dev/null || cd "$GUI_DIR" && python3 -m http.server "$GUI_PORT" 2>/dev/null
     else
         # Fallback to simple HTTP server
         cd "$GUI_DIR"
         python3 -m http.server "$GUI_PORT" 2>/dev/null
     fi
 elif command -v python &> /dev/null; then
     cd "$GUI_DIR"
     python -m SimpleHTTPServer "$GUI_PORT" 2>/dev/null
 else
     echo_error "No HTTP server available (python/python3 required)"
     echo_info "Please install Python to use the GUI"
     exit 1
 fi

⚠️ Potential issue | 🔴 Critical

Undefined function reference in confirmation prompt.

Line 54 calls echo_info() but this function is not defined in the script. The script defines echo_step(), echo_success(), echo_warning(), and echo_error() at lines 35-38, but not echo_info().

Apply this fix:

 echo_step() { echo -e "\n${CYAN}[*] $1${NC}"; }
 echo_success() { echo -e "${GREEN}[+] $1${NC}"; }
 echo_warning() { echo -e "${YELLOW}[!] $1${NC}"; }
 echo_error() { echo -e "${RED}[-] $1${NC}"; }
+echo_info() { echo -e "${CYAN}[*] $1${NC}"; }

Committable suggestion skipped: line range outside the PR's diff.

In scripts/uninstall-cliproxyapi.sh around lines 48 to 78, the script calls the
undefined function echo_info at two places (the preservation message and
"Uninstall cancelled"); replace those echo_info calls with the existing
echo_step function (or implement a short echo_info wrapper that delegates to
echo_step) so the informational messages use a defined logger and the script no
longer references an undefined function.

⚠️ Potential issue | 🟠 Major

Unused REPO_URL variable.

Line 9 defines REPO_URL="https://github.com/..." but it's never used in the script. The update logic uses RELEASE_API (line 10) for prebuilt downloads, or pulls from existing CLONE_DIR (line 11) for source updates.

Apply this fix to remove dead code:

-REPO_URL="https://github.com/router-for-me/CLIProxyAPIPlus.git"
 RELEASE_API="https://api.github.com/repos/router-for-me/CLIProxyAPIPlus/releases/latest"

In scripts/update-cliproxyapi.sh around lines 9 to 16, the REPO_URL variable is
defined but never used; remove the unused REPO_URL declaration and any
references to it (if present elsewhere) so the script only defines and uses
RELEASE_API, CLONE_DIR, BIN_DIR, BINARY_NAME, USE_PREBUILT, and FORCE; run a
quick grep to confirm REPO_URL is not referenced elsewhere and update comments
or docs if they mention the removed variable.

⚠️ Potential issue | 🔴 Critical

Undefined echo_info() function usage.

Lines 61 and 70 call echo_info() which is not defined. The script only defines echo_step(), echo_success(), echo_warning(), and echo_error() at lines 35-38.

Add the missing function definition:

 echo_step() { echo -e "\n${CYAN}[*] $1${NC}"; }
 echo_success() { echo -e "${GREEN}[+] $1${NC}"; }
 echo_warning() { echo -e "${YELLOW}[!] $1${NC}"; }
 echo_error() { echo -e "${RED}[-] $1${NC}"; }
+echo_info() { echo -e "${CYAN}[*] $1${NC}"; }

Committable suggestion skipped: line range outside the PR's diff.

In scripts/update-cliproxyapi.sh around lines 58 to 70 the script calls
echo_info() but that helper is not defined (only
echo_step/echo_success/echo_warning/echo_error exist); add a new echo_info
function consistent with the other helpers (print to stdout with the same
prefix/format as the other echo_* functions) near the existing helper
definitions (around lines 35-38) so calls to echo_info succeed and formatting
remains consistent.

P2: Shell detection logic is flawed - $BASH_VERSION is always set because this script runs under bash (shebang #!/usr/bin/env bash). This means zsh users will incorrectly have PATH added to .bashrc instead of .zshrc. Use $SHELL environment variable to detect the user's actual login shell instead.

Check if this issue is valid — if so, understand the root cause and fix it. At scripts/install-cliproxyapi.sh, line 256:

<comment>Shell detection logic is flawed - `$BASH_VERSION` is always set because this script runs under bash (shebang `#!/usr/bin/env bash`). This means zsh users will incorrectly have PATH added to `.bashrc` instead of `.zshrc`. Use `$SHELL` environment variable to detect the user&#39;s actual login shell instead.</comment>

<file context>
@@ -0,0 +1,389 @@
+# Add ~/.local/bin to PATH if not already
+echo_step &quot;Configuring PATH...&quot;
+SHELL_RC=&quot;&quot;
+if [ -n &quot;$BASH_VERSION&quot; ]; then
+    SHELL_RC=&quot;$HOME/.bashrc&quot;
+elif [ -n &quot;$ZSH_VERSION&quot; ]; then
</file context>

P2: This shell detection logic will always detect bash because $BASH_VERSION is set by the bash interpreter running the script, not by the user's login shell. Use $SHELL instead to correctly detect the user's shell config file.

Example fix:

case "$SHELL" in
    */bash) SHELL_RC="$HOME/.bashrc" ;;
    */zsh) SHELL_RC="$HOME/.zshrc" ;;
    *) SHELL_RC="$HOME/.profile" ;;
esac

Check if this issue is valid — if so, understand the root cause and fix it. At scripts/AGENTS.md, line 234:

<comment>This shell detection logic will always detect bash because `$BASH_VERSION` is set by the bash interpreter running the script, not by the user&#39;s login shell. Use `$SHELL` instead to correctly detect the user&#39;s shell config file.

Example fix:
```bash
case &quot;$SHELL&quot; in
    */bash) SHELL_RC=&quot;$HOME/.bashrc&quot; ;;
    */zsh) SHELL_RC=&quot;$HOME/.zshrc&quot; ;;
    *) SHELL_RC=&quot;$HOME/.profile&quot; ;;
esac
```</comment>

<file context>
@@ -117,8 +143,118 @@ Select-String -Path &quot;scripts\NEW_SCRIPT.ps1&quot; -Pattern &quot;ErrorActionPreference&quot;  #
+esac
+
+# Detect shell config file
+if [ -n &quot;$BASH_VERSION&quot; ]; then
+    SHELL_RC=&quot;$HOME/.bashrc&quot;
+elif [ -n &quot;$ZSH_VERSION&quot; ]; then
</file context>

P2: Logic bug: is_running check after removing PID file will always return false. The rm -f "$PID_FILE" on line 97 removes the file that is_running() depends on, so the subsequent check can never detect if the process failed to stop. Move the PID file removal after the final verification, or check the process directly using the stored $PID variable.

Check if this issue is valid — if so, understand the root cause and fix it. At scripts/start-cliproxyapi.sh, line 33:

<comment>Logic bug: `is_running` check after removing PID file will always return false. The `rm -f &quot;$PID_FILE&quot;` on line 97 removes the file that `is_running()` depends on, so the subsequent check can never detect if the process failed to stop. Move the PID file removal after the final verification, or check the process directly using the stored `$PID` variable.</comment>

<file context>
@@ -0,0 +1,207 @@
+        if ps -p &quot;$PID&quot; &gt; /dev/null 2&gt;&amp;1; then
+            return 0
+        else
+            rm -f &quot;$PID_FILE&quot;
+            return 1
+        fi
</file context>

P2: The GUI_PORT variable is not passed to the API server, so the --port option is ignored. The API server will always run on its hardcoded port 8318.

Check if this issue is valid — if so, understand the root cause and fix it. At scripts/gui-cliproxyapi.sh, line 190:

<comment>The GUI_PORT variable is not passed to the API server, so the `--port` option is ignored. The API server will always run on its hardcoded port 8318.</comment>

<file context>
@@ -0,0 +1,203 @@
+if command -v python3 &amp;&gt; /dev/null; then
+    if [ -f &quot;$API_SERVER&quot; ]; then
+        # Use Python API server with management endpoints
+        python3 &quot;$API_SERVER&quot; 2&gt;/dev/null
+    else
+        # Fallback to simple HTTP server
</file context>

P0: Function echo_info is used but never defined. This will cause the script to fail at runtime with 'command not found'. Add the missing function definition alongside the other echo helper functions.

Check if this issue is valid — if so, understand the root cause and fix it. At scripts/update-cliproxyapi.sh, line 38:

<comment>Function `echo_info` is used but never defined. This will cause the script to fail at runtime with &#39;command not found&#39;. Add the missing function definition alongside the other echo helper functions.</comment>

<file context>
@@ -0,0 +1,234 @@
+echo_step() { echo -e &quot;\n${CYAN}[*] $1${NC}&quot;; }
+echo_success() { echo -e &quot;${GREEN}[+] $1${NC}&quot;; }
+echo_warning() { echo -e &quot;${YELLOW}[!] $1${NC}&quot;; }
+echo_error() { echo -e &quot;${RED}[-] $1${NC}&quot;; }
+
+echo -e &quot;${MAGENTA}&quot;
</file context>

P1: Server binds to all network interfaces instead of localhost only. This exposes the management API to the entire network, allowing remote control of server start/stop, OAuth, and updates. For a local management API, bind to 127.0.0.1 instead.

Check if this issue is valid — if so, understand the root cause and fix it. At scripts/cliproxyapi-api-server.py, line 299:

<comment>Server binds to all network interfaces instead of localhost only. This exposes the management API to the entire network, allowing remote control of server start/stop, OAuth, and updates. For a local management API, bind to `127.0.0.1` instead.</comment>

<file context>
@@ -0,0 +1,309 @@
+    if gui_dir.exists():
+        os.chdir(gui_dir)
+
+    with socketserver.TCPServer((&quot;&quot;, PORT), APIHandler) as httpd:
+        print(f&quot;API Server running on http://localhost:{PORT}&quot;)
+        print(f&quot;GUI available at http://localhost:{PORT}&quot;)
</file context>

Inconsistent naming for output functions across bash scripts. This script defines echo_step() while all other scripts in this PR (start-cliproxyapi.sh, update-cliproxyapi.sh, cliproxyapi-oauth.sh, gui-cliproxyapi.sh, uninstall-cliproxyapi.sh) use echo_info() for informational output.

For consistency, rename echo_step() to echo_info() throughout this script. This will establish a consistent convention across all bash scripts.

Missing echo_info() function definition. The script calls echo_info() on lines 54, 60, 121, 122, 139, 159, 160, and 164, but only defines echo_step(), echo_success(), echo_warning(), and echo_error(). This will cause runtime errors when echo_info() is called.

Add the missing function definition:

echo_info() { echo -e "${CYAN}[*] $1${NC}"; }

Alternatively, for consistency with most other scripts in this PR, you could use echo_info() everywhere and remove echo_step(), or standardize on one naming convention across all scripts.

The custom port specified via --port flag is not passed to the Python API server. The cliproxyapi-api-server.py script has a hardcoded PORT = 8318 on line 15, so even if a user specifies --port 9000, the API server will still run on port 8318.

To fix this, pass the GUI_PORT as an argument or environment variable to the Python script:

GUI_PORT=$GUI_PORT python3 "$API_SERVER" 2>/dev/null

Then update the Python script to read from the environment:

PORT = int(os.environ.get('GUI_PORT', 8318))

Using curl via subprocess to make HTTP requests is inefficient and requires an external dependency. Python has built-in libraries for HTTP requests that would be more reliable and portable.

Consider using Python's urllib.request (built-in) or checking if requests is available:

import urllib.request
import urllib.error

def handle_models(self):
    """Get available models"""
    try:
        req = urllib.request.Request(
            "http://localhost:8317/v1/models",
            headers={"Authorization": "Bearer sk-dummy"}
        )
        with urllib.request.urlopen(req, timeout=5) as response:
            data = json.loads(response.read())
            models = [m["id"] for m in data.get("data", [])]
            self.send_json({"models": models})
    except Exception as e:
        self.send_json({"models": [], "error": str(e)})

The documentation shows echo_step() as the standard function name, but most bash scripts in this PR (start-cliproxyapi.sh, cliproxyapi-oauth.sh, gui-cliproxyapi.sh) use echo_info() instead. This inconsistency between documentation and implementation will confuse future contributors.

Update the documentation to reflect the actual convention used in most scripts:

echo_info() { echo -e "${CYAN}[*] $1${NC}"; }

Or alternatively, standardize all scripts to use echo_step() if that's the preferred naming.

The PID variable should be quoted when writing to the file for better shell script practices, although in this case it's unlikely to cause issues since PIDs don't contain spaces.

Change:

echo $PID > "$PID_FILE"

To:

echo "$PID" > "$PID_FILE"

The uninstall script completely removes ~/.factory/config.json when --all flag is used. This will delete all custom model configurations that users may have set up, not just CLIProxyAPI-Plus models. If users have configured other custom models in Factory Droid, those will be lost.

Consider either:

1. Warning the user more explicitly that this will remove ALL custom models
2. Attempting to remove only CLIProxyAPI-Plus entries from the config.json (using jq or similar)
3. Creating a backup before deletion

At minimum, add a more explicit warning message before this deletion:

echo_warning "This will remove ALL Factory Droid custom models, not just CLIProxyAPI-Plus models"

Inconsistent naming for output functions across bash scripts. The update-cliproxyapi.sh script uses both echo_step() (defined on line 35) and echo_info() (called on lines 61, 70, 113, etc.) without defining echo_info(). This will cause runtime errors when the undefined function is called.

For consistency with other scripts in this PR (start-cliproxyapi.sh, cliproxyapi-oauth.sh, gui-cliproxyapi.sh, uninstall-cliproxyapi.sh which all use echo_info()), rename echo_step() to echo_info() in this script.

Import of 'parse_qs' is not used.

gui-cliproxyapi.sh starts the Python management server (cliproxyapi-api-server) as a long-lived HTTP API without any authentication or CSRF protection, exposing sensitive operations like start/stop/restart and config access over HTTP on port 8318. Because the backend binds to all interfaces and sets permissive CORS, any process on the local network or any web page running in the user’s browser can issue cross-origin requests to control the proxy and read configuration data. Restrict the management server to 127.0.0.1, add a per-user auth token checked on each request, and narrow CORS to the local GUI origin instead of * before starting it here.